Packet technologies (e.g., Ethernet, IP) are fundamentally asynchronous, optimized for the bursty nature of data traffic, and provide no inherent timing transfer (frequency and time) capabilities. However, packet technologies like Ethernet are quickly replacing existing provider network infrastructures (widely based on time division multiplexing (TDM) technologies like PDH and SDH). This is due to the relatively higher bandwidths and low costs of packet networking devices, as well as to enhancements in Quality of Service (QoS), Operations, Administration and Maintenance (OA&M), congestion management, and resiliency.
One of the important capabilities missing from a total convergence to packet networking (with Ethernet currently being the technology of choice) is the ability to provide timing and synchronization natively within the network. This would provide Ethernet with the capability to transport time-sensitive applications (such as Circuit Emulation Services (CES) over packet) and to distribute precise frequency and time references.
Time and frequency synchronization plays a crucial role in mobile backhaul networks. Cellular base stations derive their carrier radio frequencies from a highly accurate reference clock, usually within 50 parts-per billion (ppb). This reference clock is typically derived from synchronous TDM interfaces or from expensive GPS receivers located at the base station. Without timing information traceable to a highly accurate Primary Reference Clock (PRC), local interference between channel frequencies, as well as mutual interference with neighboring base stations will occur, ultimately causing dropped calls and degrading the overall user experience. Each base station requires an accurate synchronization reference in order to prevent call drops during handoffs. Call handoffs during mobile client roaming also suffer perceptible delays when base station clocks are not sufficiently synchronized.
Mobile networks fall into two categories, Frequency Division Duplexing (FDD), which uses two separated frequency bands to transmit/receive, and Time Division Duplexing (TDD), which transmits and receives on a single frequency band. Time synchronization (in addition to frequency synchronization) is needed for LTE-TDD, WiMAX TDD, CDMA networks (popular in North America), and TD-CDMA and TD-SCDMA, while only frequency synchronization is required for LTE-FDD, GSM (global system for mobile communications), W-CDMA, and other wireless technologies. Even with the use of LTE-FDD, new LTE mobile services such as network MIMO and location-based services will demand accurate time synchronization.
In the case where clock transfers have to be done end-to-end with no assistance from the packet network (in the form of hop-by-hop Boundary Clocks (BCs) or Transparent Clocks (TCs)), there are no reference clocks traceable to a PRC at both ends of the packet network, or in the absence of a network-wide GPS service, a receiving timing-dependent terminal node has to use an adaptive timing technique to reconstruct the timing signal of the transmitting timing reference source. The receiving terminal source would commonly use a “packet-based” clock recovery mechanism that slaves the receiver clock to a transmitter clock. The clock recovery mechanism is able to process transmitted clock samples (timestamps) encoded within the packet data stream to generate timing signal for the receiver. The purpose of the clock recovery mechanism is to estimate and compensate for the frequency drift occurring between the oscillators of the transmitter clock and the receiver clock. However, the presence of packet delay variation (PDV) and packet losses affects the performance of the clock estimation/compensation process, making the transmitter clock appear faster or slower than it actually is, and ultimately, causing the propagation of mostly wander up to the receiver clock signal. (Wander is clock noise less 10 Hz while jitter is clock noise equal or greater than 10 Hz.)
IEEE 1588 PTP Message Flow
The IEEE 1588v2 PTP defines a packet-based synchronization protocol for communicating frequency, phase and time-of-day information from a master to one or more slaves with sub-microsecond accuracy. PTP relies on the use of accurately timestamped packets (at nanosecond level granularity) sent from a master clock to one or more slave clocks to allow them to (frequency or time) synchronize to the master clock. Synchronization information is distributed hierarchically, with a GrandMaster clock at the root of the hierarchy. The GrandMaster provides the time reference for one or more slave devices. These slave devices can, in turn, act as master devices for further hierarchical layers of slave devices.
The PTP message exchange process (i.e., the PTP Delay Request/Delay Response flow) between a master 1 and a slave 3 is performed as follows and illustrated in FIG. 1. IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay-Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay-Resp). A Sync message is transmitted by a master 1 to its slaves 3 and either contains the exact time of its transmission or is followed by a Follow_Up message containing this time. In a two-step ordinary or boundary clock, the Follow_Up message communicates the value of the departure timestamp for a particular Sync message.
FIG. 1 illustrates the basic pattern of synchronization message exchanges for the two-step clocks. The master 1 sends a Sync message to the slave 3 over a network 2 and notes the time T1 at which it was sent. The slave 3 receives the Sync message and notes the time of reception T2. The master 1 conveys to the slave the timestamp T1 by one of two ways: 1) Embedding the timestamp T1 in the Sync message. This requires some sort of hardware processing (i.e., hardware timestamping) for highest accuracy and precision. 2) Embedding the timestamp T1 a Follow_Up message as shown in FIG. 1. Next, the slave 3 sends a Delay_Req message to the master 1 and notes the time T3 at which it was sent. The master receives the Delay_Req message and notes the time of reception T4. The master 1 conveys to the slave 3 the timestamp T4 by embedding it in a Delay_Resp message.
At the end of this PTP messages exchange, the slave 3 possesses all four timestamps {T1, T2, T3, T4}. These timestamps may be used to compute the offset of the slave's clock 5 with respect to the master clock 4 and the mean propagation time of messages between the two clocks. The computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal—symmetrical communication path. Clock frequencies change over time, so periodic message exchanges are required. Because these clock variations change slowly, the period between message exchanges is typically on the order of milliseconds to seconds.
Time/frequency can be transferred in an end-to-end fashion from master 1 to slave 3 without involving the intermediate network nodes 6 as illustrated in FIG. 2. In this scenario the slave 3 is solely responsible for correctly recovering the master clock signal. Compared to the other methods (e.g., using hop-by-hop Boundary Clocks or Transparent Clocks), time/frequency transfer here is more challenging because the slave 3 is exposed to all the PDV generated by the intermediate packet network 2 (as illustrated in FIG. 3 and FIG. 4). The processing and buffering of packets in network devices (switches, routers, etc.) introduce variations in the time latency of packets traversing the packet network 2 that tend to degrade the clock signal transferred. The PDV inherent in packet networks is a primary source of clock noise. The recovered clock from the PTP timing signal at the slave 3 contains clock noise (contributed largely by PDV) that needs to be removed or attenuated. A filtering process is used at the slave 3 to filter out the clock noise, thus generating a “smooth” clock output.
There are several clock synchronization techniques that estimate clock skew through linear regression, linear programming and convex hull methods. Specifically, [1] describes a number of methods one of which is a linear regression technique. The problem with linear regression algorithms is that they are usually not robust to presence of large outliers and thus only valid and work well for certain PDV models (e.g. Gaussian). A more complicated approach is proposed in [1][2] where a linear programming technique is used to estimate the clock skew in one-way network delay measurements. The technique shows improvement in performance compared to other existing algorithms. In [3][4] skew estimation is achieved through the computation of convex hull generated from one-way delay measurements. The authors claim that convex-hull approach provides better insight and handling of error metrics compared to linear regression or linear programming techniques. An extension of this technique is introduced by [5] where both the offsets and skew are estimated by a lower and upper convex hull approach that relies on using downstream (master to slave) and upstream (slave to master) delay measurements.
When clock synchronization is done in an end-to-end manner over a packet network, the timing protocol messages are exposed to packet network artifacts like packet delay variations (PDVs) and packet losses. The PDV inherent in packet networks is a direct contributor to the noise in the recovered clock at the end system.
An object of the present invention is to recover the master clock accurately at the slave in the face of all the PDV generated by the intermediate packet network.
It is a further object of the present invention to achieve accurate and robust synchronization over IEEE 1588 for critical applications that require stringent synchronization margins.